Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/92mar/bgpisis-minutes-92mar.txt

Text File | 1993-02-17 | 12KB | 261 lines

These Minutes should be considered a rough draft only - Megan 04/03/92
==============================================================================
           Notes from BGP WG - San Diego IETF - 3/19/92 9am
             [David Bolen - [e-mail]]
==============================================================================


* Discussion of BGP-4 Extensions

   The largest portion of the BGP meeting was concerned with the discussion
   of the BGP4 document authored by Vince Fuller and Tony Li.  The additions
   were made primarily to add the necessary support into BGP for classless
   inter-domain routing (CIDR).

   * IP Prefixes vs. Masks

    The need for carrying some form of network masks as part of BGP
    was discussed in the light of the need for classless inter-domain
    routing (CIDR).  The necessary information could be carried either
    as a combination of network and netmask, or it could be encoded
    as a prefix with a length value.

    A key difference between the two proposals is that carrying an entire
    mask allows the use of non-contiguous masks, while a prefix requires
    that the mask be contiguous.

    The general consensus of the group was that non-contiguous masks
    presented several problems, especially in routing table lookups
    (where multiple entries can match), and in the automatic aggregation
    of such masks (which we aren't sure how to do yet, and it's critical
    for CIDR).  Therefore prefixes, being more deterministic, were a
    better choice for BGP-4.

    It was agreed that masks could prove useful later when some of the
    trickier issues have been dealt with.  In that case, they could
    always be added to a later version of the protocol.

    >> Use prefixes rather than masks.

   * Aggregation rules from BGP-4 document

    The group discussed the various rules presented in the BGP-4
    document to handle aggregation:

    * Rule 1 - always do longest match.
    * Rule 2 - Inject "poison" routes to avoid loops.  In a multi-homed
           case, if the aggregator is the primary provider, the
           aggregator must also announce the longer prefix for the
           client (to override the same announcement via that client's
           other provider).  If the aggregator is not primary, this
           additional announcement is not necessary.
    * Rule 3 - Punch hole to sever old route when switching providers.
           This requires an announcement withdrawal mechanism in BGP.

    In particular, rule 3 was discussed in that it required the addition
    of a withdrawal mechanism in BGP to withdraw a previous announcement
    (along the lines of the facility provided within IDRP).

    The largest concern if this wasn't provided was that packets could
    flow partially down a bad path before they were either bounced or
    black-holed.  Also, traceroute would no longer function properly in
    such a case.

    The general consensus was that these problems were not critical
    enough to warrant the added complexity of the withdrawal mechanism,
    especially when interoperability with older implementations of BGP
    that didn't have such a mechanism was taken into account.

    >> Rules 1 & 2 ok - removing Rule 3.

   * Support for AS sets

    In order to be able to handle multi-level aggregation, the ability
    to specify an AS_PATH that included AS sets rather than simply a
    sequence is very important.  If AS-1 and AS-2 both flow packets
    through AS-3, AS-3 would like to be able to aggregate routes if
    AS-1 and AS-2 fall under the same prefix.  Since they represent
    different AS_PATHs, that is currently not possible.

    IDRP was brought up as an example of using sets.  In IDRP, the
    RD_PATH (like BGP's AS_PATH) is an overall sequence of elements,
    where each element is either an RD sequence, or an RD set.  An RD
    set implies that the packets flow through one or more of the RDs
    in the set, but not necessarily all of them, and no order is
    specified.

    IDRP also provides for the concept of routing confederations, which
    is a method for aggregating several routing domains into a single
    routing domain confederation (RDC) which is generally treated just
    like an RD when it appears in the RD_PATH.

    Using confederations was considered more powerful than just sets,
    but also more complicated, and not required for the CIDR support
    we want to include in BGP-4.

    A possibility was just to turn BGP's AS_PATH into a set, which would
    imply no particular order of AS traversal.  However, this would
    prevent any route filtering based on AS order.  Matt Mathis suggested
    having an AS_PATH that started with a sequence, and was followed
    by a set.

    This discussion also brought up the fact that the AS_PATHs would
    probably be growing as this structure would encourage the size of an
    AS to be small, which led to thinking about the assignment of AS
    numbers hierarchically in order to allow them to be aggregated
    as well.  Finally, the discussion turned to whether AS values
    should be increased to 32-bit rather than 16-bit.  Some people
    strongly felt it should be increased in size, especially now as we
    were making these other changes.

    >> General consensus for requiring sets/sequences, but not
       confederations.  Stick with 16-bit AS, although moving to 32-bit
       at the same time as the AS set change was strongly discussed.

   * Parallel BGP sessions

    During the discussion, the issue of being able to run parallel BGP
    sessions turned out to primarily address the problem of wanting to
    filter on an AS wherever it shows up in the AS_PATH, rather than just
    the first AS (as is common in current applications).  This is an
    implementation problem rather than one with the protocol.

    The point was made that it can be dangerous to run two BGP connections
    in the same host with the only exchange of information between them
    being a routing table handled through a common IGP.

    Therefore, it was decided that it wasn't worth changing the protocol
    to handle what was essentially an implementation issue.

    >> Dropped

   * NEXT_HOP Handling

    The NEXT_HOP discussion centered around the issue of allowing one
    BGP peer to pass along the address of some other host on a common
    wire as the NEXT_HOP value rather than using its own address.
    The knowledge that the other host was available would commonly have
    been determined via an IGP (such as OSPF), or by the fact that the
    BGP peer was maintaining sessions with both hosts.

    Yakov brought up IDRP as an example of this functionality but
    under control of the source, which can choose to add additional
    options to a NEXT_HOP announcement controlling whether the
    recipient can propagate the NEXT_HOP value.  This addresses the
    multiple BGP session, but not the IGP case.

    The concern with allowing this optimization was that the new host
    was being included in the NEXT_HOP announcement without it being
    aware of its involvement.  Under certain circumstances this can
    be very useful, but it can also easily violate policy or routing
    rules.  It deserved some further investigation, but for now (and
    at least for BGP-4), it was decided to keep the current definition
    of NEXT_HOP.

    >> Keep definition/use same as is currently specified.


* BGP/OSPF Interaction Document

   A short discussion of the current BGP/OSPF interaction document by
   Kannan Varadhan took place.  The document is nearing completion, and
   only had a few changes since the previous IETF.

   * Tag bits

    If the upper ("trusted") bit of the tag is set, the tag was
    system generated or configured, and the following 3 bits are
    used to encode the completeness of the route and how it should
    be handled, as follows:

        pl 00        01        10        11
    c  0  <EGP> <l>        <EGP><l,nh>     never export     reserved
       1  <IGP> <l>     <IGP><l,nh>     out of band      reserved


    Matt Mathis suggested that the term "trusted" may not be the
    most appropriate (it could be taken to imply that the network
    administrator isn't trusted).  Tony Li suggested the substitution
    of the term "automatic" instead.

    >> Change "trusted" keyword to something like "automatic".

   * NEXT_HOP handling with subnets

    This issue dealt with an optimization for handling the case where
    you learn a set of routes through OSPF that represented an entire
    subnet for a network, and what to assign NEXT_HOP to in that case.
    The optimization in question was whether or not you still had to
    always place yourself in NEXT_HOP rather than the node through
    which the subnets were routed.

    It was agreed that this represented an implementation optimization
    and should not be dictated by this document, but left to the choice
    of the developer.

    >> Leave optimization to developers.


   A new revision of the document will be published with a fairly short
   deadline for comment, so that the document can then proceed through the
   standards process.


* IBGP & OSPF Discussion

   Jeff Honig held a discussion about possible problems with the use of
   IBGP, and how the same information might be propagated through an IGP
   (specifically OSPF) rather than with IBGP connections.  The main concerns
   with IBGP were the need for scaling of N^2 connections, and the bandwidth
   utilized for IBGP traffic.

   Enhancements to OSPF that were being discussed to be used to carry the
   external information included:
    - OSPF Variable Tags (to allow the encoding of a complete AS_PATH)
    - New OSPF Path Attribute LSA to propagate path/attribute pairs
      (to send unique path/attribute information around in separate
       packets that were referenced by the route announcements)

   During the discussion, the general feeling was that the difference between
   IBGP resource usage (N-1 TCP connection blocks on each border router (BR),
   and bandwidth) and the resource required to distribute the same information
   via an IGP was not significantly different.  Also, trying to store external
   information in internal routers could cause physical resource problems
   (such as memory) for those routers.

   One agreed issue with IBGP was router discovery.  Using the IGP to aid
   the BRs in discovering each other was considered an important feature.
   At a minimum, all that would be required is a single flag bit to be
   carried by the IGP to indicate that a host was a BR.  Ideally several
   bits to encode additional information would be useful.

   >> General discussion felt that IBGP resource utilization was not
      significantly more than that introduced by having the IGP carry EGP
      information.

   >> Agreement was reached that border router discovery was important and
      that some bits (at least 1) should be requested from IGPs such as
      OSPF to support this.


* BGP <-> IS-IS Interaction Document

   Sharad Sanghi held a discussion on the BGP/IS-IS interaction document
   that he and Atul Bansal had authored.

   The general issues were similar to the BGP/OSPF interaction document.
   The basic question discussed was in regards to the advantages and
   disadvantages to doing route injection vs. piggybacking vs. just using
   IBGP.

   As with the previous IBGP vs. IGP (OSPF) discussion, the group felt
   that it was not clear that the savings in resources by eliminating IBGP
   and using IS-IS to carry external routing information was worth the
   work to transfer the routes.

   Router discover was still very useful, so adding bits to IS-IS (which
   it already has room to support) is definitely desired.  Using IBGP with
   these bits for discovery should be fine for stub domains.  For transit
   systems, it could prove useful to consider the injection/piggybacking
   cases, which should be studied further.